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TO ALL WHOM IT MAY CONCERN: 

BE IT KNOWN that WE, Lance Eason, Carolyn Faour, David 
Harvey, and Neil Oholakia, citizens of the United States of America, 
residing in the State of Texas, have invented new and useful improvements 
in 

WORKFLOW ENCAPSULATION IN STATELESS ENVIRONMENTS 
of which the following is a specification: 
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1 CROSS-REFERENCE TO RELATED APPLICATION 

2 This application claims priority based upon Provisional Application 

3 Filing No. 60/158,731 filed October 11, 1999 titled ARCHITECTURE FOR 

4 CHANNEL-INDEPENDENT ENCAPSULATION OF WORKFLOW IN 

5 STATELESS ENVIRONMENTS. 

6 BACKGROUND OF THE INVENTION 

7 1 . Field oif the Invention: 

8 The present invention relates generally to distributed computer 

9 systems, and more specifically to a system for processing user requests, 

1 0 which separates process state from presentation. 

1 1 2. Description of the Prior Art: 

12 The rising popularity of computer communication systems such as the 

13 internet has given rise to new techniques for performing business 

14 transactions. It is not uncommon for several applications to carry on an 

15 interactive dialogue with multiple simultaneous users to perform many types 

1 6 of business transactions. 

17 Internet based applications for performing business transactions 

18 generally include a number of pages which are presented to a remote user in 

19 some logical sequence. Each page has information which is presented to 
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1 the user, and includes some type of input technique by which the user can 

2 enter information and make selections. Each page typically contains 

3 associated code which determines whether the user's input is valid, and 

4 determines which page comes next. 

5 This approach to preparing internet-based applications is both 

6 demanding and somewhat limited. Application designers must be 

7 conversant with various aspects of web page design, as well as with the 

8 underlying business processes. Once an application has been completed, it 

9 may be copied and modified to be used again in the future, but is not very 

10 flexible. Significant modifications must be made to various details of the 

1 1 pages presented to the user. Entirely new application code must be written 

12 to adapt the application to a significantly different user interface, such as an 

13 audible interface to be used through the telephone as opposed to a visual 

1 4 interface to be used with a computer. 

15 It would be desirable to provide a system and method for running 

16 such applications which was simultaneously more flexible and useful, and 

17 easier to program. 

18 
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1 SUMMARY OF THE INVENTION 

2 In accordance with the present invention, a system for running 

3 applications such as may be used over the internet separates the logical 

4 workflow processes of the application from views presented to a user. 

5 Separate process flow modules are used to provide state code for executing 

6 transactional applications. Logical views are designated by these modules 

7 in response to user input. Actual views presented to a user are derived from 

8 these logical views according to the status of the user and the 

9 communication channel over which the transaction is being performed. 

10 Process flow modules can be reused with different sets of user interface 

1 1 views to provide a variety of user interfaces without significant recoding. 
12 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 Additional objects, features and advantages will be apparent in the 

3 written description which follows. 

4 Figure 1 is a block diagram of a series of interrelated web pages; 

5 Figure 2 is a state diagram of control steps corresponding to the 

6 diagram of Figure 1 ; 

7 Figure 3 is a block diagram illustrating a preferred system architecture 
Q 8 in accordance with the present invention; and 



9 Figures 4 and 5 are flow charts showing operation of the system of 



y 10 Figure 3. 



11 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 



2 It will be appreciated by those skilled in the art that the architecture 

3 and system described herein can be implemented using any number of 

4 widely available software systems and tools. Although the following 

5 description is given with respect to an application for performing transactions 

6 over the internet, it will be appreciated by those skilled in the art that the 

7 techniques described herein may be used with a variety of transactional 

8 systems. 

9 Figure 1 represents a set of interconnected web pages for 

10 implementing a business transaction in an internet environment. Web pages 

11 11-16 preferably each provide data and graphic information to a user. 

12 Each page 11-16 may contain responsive means, such as buttons, menus, 

13 or data entry fields for a user to enter information into the transaction. Once 

14 data is entered, flow of control passes to another page which presents 

1 5 additional information to the user. 

1 6 For some pages, in this example 1 1 and 1 3, more than one next page 

17 may be selected depending upon the nature of the input received from the 

18 user. In fact, loops can be formed, such as illustrated by pages 12 and 13. 

19 This illustrates a hypothetical control flow in which a user may perform a 

20 number of actions while moving back and forth between pages. An example 

21 of such a control flow may be adding purchased items to a shopping cart 
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1 until all designated items have been selected, followed by submitting a final 

2 order. 

3 In prior art implementations, each page 11-16 must be programmed 

4 to contain all of the code for presenting its information to the user, and 

5 receiving input. In addition, the determination of flow of control between 

6 pages must be made at each page. 

7 In accordance with a preferred embodiment of the present invention, 

8 the control information used to traverse from page to page is extracted from 

9 the web pages and encapsulated into separate workflow modules, also 

10 referred to as process modules. Figure 2 illustrates a workflow module 

11 corresponding to the web pages of Figure 1. In Figure 2, states 21 - 26 

12 correspond to pages 11 -16, respectively. Figure 2 is a state diagram of a 

13 well-known type, in which decisions are made at each node, and control 

1 4 passed to a following node when an event is completed. 

15 Within each node of the state diagram, an input or request from the 

1 6 user is received, processed and appropriate output generated. Control then 

17 passes to the next state which awaits the next input from the user. Because 

18 of the step-by-step nature of typical remote transactions performed over the 

1 9 internet, state diagrams such as that shown in Figure 2 are extremely useful 

20 for embodying business transaction processes. 
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1 Conceptually, the process of interacting with the remote user is 

2 broken into two components. The first component is referred to herein as 

3 the workflow component, which contains the logical processes of an 

4 application for managing interactions between a user and the larger system. 

5 The workflow portion of an application is that portion which handles incoming 

6 requests from a user, and performs any underlying transactions. That is, the 

7 workflow portion of the application is that portion which directs the making of 

8 queries on an underlying database, enters transactions such as sales to the 

9 database, and similar functions. 

10 The workflow portion of an application has three major 

11 responsibilities. First, it handles requests from a user, and manages the 

12 process of fulfilling those requests. As the user interacts with the user 

13 interface portion of the application, events are generated as described 

14 above. The workflow portion of the application interprets these events and 

1 5 takes appropriate action in response. 

16 Second, workflow modules embody the rules and constraints defining 

17 what actions are valid for a user to take at any given time. As described 

18 above, the workflow module functions as a state machine for the application. 

19 At any given state, only certain user responses are considered valid. The 

20 workflow module determines whether a user request is valid, and proceeds 

21 to the next state if it is. If an incoming request is not valid, the workflow 

22 module manages the error handling process. 
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1 Third, the workflow module is responsible for directing the course of 

2 interactions with the user. After processing a request, the workflow module 

3 determines the appropriate response and causes an appropriate 

4 presentation to be made to the user's interface. The workflow module 

5 generates logical views of the information to be presented to the users, 

6 which is converted to a physical view to be presented to the user. 

7 The presentation portion of the application consists of a number of 

8 views, roughly corresponding to web pages in most applications, which 

9 contain the information to be presented to each user. The job of the 

10 workflow module is to identify the next view to be presented, and provide 

11 information which must be used to provide data within that view. The 

12 presentation portion of the application handles the task of formatting the view 

13 appropriately to be presented to the user, and all other details of the user 

14 interface itself. Thus, the presentation of information to the user is separated 

15 from the logical flow of the underlying business process. As described 

1 6 below, this provides a great flexibility for web-based applications. 

17 Referring to Figure 3, a system for executing applications to interface 

18 with remote users is designated generally with reference number 30. 

19 Content engines 32, 34 are connected to interfaces 36, 38 respectively. 

20 Both content engines 32, 34 are connected to a single set of process 

21 modules 40. Each content engine is connected to configuration data 42, 44, 

22 and to a channel adapter 46, 48. Each channel adapter 46, 48 is connected 
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1 to a set of views 50, 52 respectively. Views 50, 52 are also connected to 

2 interfaces 36, 38 respectively. 

3 Two content engines 32, 34 are illustrated to show the value of the 

4 present approach in dealing with different types of user interfaces. Interface 

5 36 can be, for example, a web based server which communicates with 

6 remote users over the internet in a known fashion. Interface 38 can be a 

7 completely separate type of interface, such as an audio interface intended to 

8 be used over the telephone. Although user interfaces for an internet based 

9 computer and a telephone present completely different interfaces to an end 

10 user, they can both be used to implement the same kind of underlying 

11 business transaction. The present invention allows a single business 

12 transaction to be defined which can be used successfully with radically 

1 3 different types of interfaces. 

14 The content engine 32 functions as a central manager and router for 

15 all requests received from a remote user. Requests are communicated from 

16 remote users to interface 36, which passes them along to content engine 32. 

17 Content engine 32 determines which process module should handle the 

18 request, and routes the request to that process module for processing. 

19 When a response is received from the process module, it is fed back to the 

20 user through channel adapter 46, views 50, and interface 36. 

21 The content engine 32 provides various services to the process 
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1 modules it manages. First, it controls the lifetime of a process module. As 

2 the user makes requests of the system, the content engine analyzes those 

3 requests. It determines whether the request should be handled by an 

4 existing instance of a process module or whether this request should be 

5 directed to a new process module instance instead. If the request is targeted 

6 towards a new instance, the content engine 32 creates that instance and 

7 initializes it with configuration information. The content engine 32 then 

8 manages references to that process module instance so that subsequent 

9 requests can be directed to it. 

10 Another service of the content engine 32 is that it decouples the 

1 1 underlying process module from the channel the request is coming through 

12 and the physical views that are presented to the user. It would have been 

13 possible to have each process module know about and handle the 

14 processing of web requests and direct the user to specific web pages as a 

15 result. The problem with this approach is two-fold. First it makes the 

16 process module usable only in a web context minimizing the reusability of 

17 that workflow. Second it directly couples the process module to a specific 

18 implementation of the presentation (in this case the web pages). Thus while 

19 the workflow and presentation are separated they are still tightly coupled to 

20 each other. 

21 Instead, in the preferred embodiment, the content engine 32 insulates 

22 the underlying process modules 40 both in the incoming and outgoing 
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1 directions. Incoming it presents a generic (channel-independent) request to 

2 the process module. This allows different content engines to be developed 

3 for different channels, and have them re-use the same library of process 

4 module workflows without modification as shown in Figure 3. This is 

5 advantageous as there are far fewer different channels for presentation than 

6 there are workflows to be managed. In the outgoing direction, all interactions 

7 with the presentation layer are managed by the content engine 32 through 

8 channel adapters 46 instead of directly by the process module 40. The 

9 process module 40 specifies logically what view should be presented and 

1 0 provides any data that it should contain, but it is the job of the content engine 

1 1 32 to determine a physical instance of that logical view to present. Thus the 

12 process module is decoupled from the physical views. This makes it 

13 possible to develop views in multiple different authoring environments and 

14 re-use workflow across multiple channels. Significantly it also allows for 

1 5 personalization of presentation. 

16 Personalization of presentation is another service provided by the 

17 content engine 32. The process module 40 logically specifies the view to be 

18 presented. The content engine 32 takes this logical designator and resolves 

19 it to a physical implementation of the view. During this resolution process, 

20 business owner defined rules may be evaluated to determine the specific 

21 physical instance. These rules can be based on user profile and channel 

22 characteristics, allowing a business owner to target views towards profile 

23 groups. Thus the process module 40 may specify that a product description 
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1 is to be displayed back to the user. The content engine 32 then applies its 

2 rules to determines that the physical presentation should be a product 

3 description web page that is, for example, Internet Explorer specific and is 

4 geared towards young high-tech professionals based on the characteristics 

5 of the user and the request. 

6 Finally, the content engine 32 also allows for personalization of the 

7 workflow presented to the user. In the same way that the request for a view 

8 is really a logical request to which personalization rules can be applied, the 

9 request for a workflow is also a logical request. In this way business owners 

1 0 can target workflows towards specific profile groups to provide a richer and 

1 1 more efficient interactions for the user. For instance, two different versions 

12 of an order process could be present in the system. One is a very simple 

13 wizard-like approach geared towards inexperienced users, while the second 

14 is a more full featured and correspondingly more complicated workflow 

15 geared towards purchasing agents and other more savvy users. The 

16 content engine can apply personalization rules that look at the profile 

17 characteristics of the user to decide which workflow is appropriate for that 

18 user. Rather than a one-size fits all approach, the interactions between the 

19 user and the application are tailored to that users capabilities and 

20 preferences. 

21 The behavior of the content engine 32 is controlled by configuration 

22 data 42. This configuration data 42 specifies the mapping between logical 
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1 and physical process modules, the mapping between logical and physical 

2 views, the personalization rules that control those mappings, and 

3 configuration parameters. The content engine 32 has no hard-coded 

4 knowledge of the process modules or views that it manages or the rules that 

5 are applied in resolving logical to physical mappings. This makes the 

6 content engine easily configurable and extensible to manage new views and 

7 workflows through a toolset rather than through receding the application. 

8 Process modules 40 embody the actual workflow. A process module 

9 instance is initiated by the content engine 32 to handle user requests. When 

1 0 the process module is first created the content engine 32 provides it with any 

1 1 configuration settings for that workflow. As it handles subsequent requests, 

12 the process module uses those configuration settings to determine certain 

1 3 aspects of its behavior. 

14 A process module interprets the request from the user. Based on the 

15 current state of the system it determines whether the request is valid. In the 

16 case of an invalid request, the process module notifies the content engine 32 

17 of the error condition. The content engine 32 then applies a policy (set 

18 through configuration data) for error handling for the particular process 

19 module and the current state. This error-handling policy can specify either a 

20 standard response (typically an error message presented to the user) or a 

21 specific view to be presented to the user which either more fully explains the 

22 error condition or allows the user to take some corrective action. 
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1 In the more typical case, where the request is valid, the process 

2 module handles the request. This handling of user requests typically involves 

3 retrieving data from the business logic layer, initiating transactions and 

4 updating the transient state of the system. The process module then 

5 decides what the appropriate response (view) is to show the user based on 

6 the new state of the system. This decision is communicated to the content 

7 engine 32, which performs the actual selection and manages the rendering 

8 of a physical view to be presented back to the user. In rendering the view, 

9 the current state data of the process module is made available to the view 

1 0 through a channel-independent mechanism. 

1 1 The purpose of the channel adapter 46 is to provide an extensible 

12 mechanism whereby the content engine 32 can manage the presentation of 

13 content developed in multiple authoring environments. The content engine 

14 32 resolves a logical view into a physical view. Based on the content type of 

15 the physical view, the content engine 32 then calls on a specific channel 

1 6 adapter 46 to resolve that view. It is the responsibility of the channel adapter 

17 46 to provide the state data of the process module to the view in a channel- 

1 8 specific way and manage the rendering of that view. 

19 Channel adapters 46, 48 thus allow views to be developed in any 

20 number of authoring environments. For instance web pages may be 

21 developed using ASP, JSP, XSL, Cold Fusion or other environments. It is 

22 then the responsibility of a channel adapter for that specific authoring 
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1 environment to manage the creation of that web page which is then returned 

2 to the content engine. 

3 Views 50 are the interface that is presented to the user. The process 

4 module 40 makes data available to the view 50 via the content engine 32 

5 and channel adapter 46 as described above. The view 50 then formats and 

6 presents that data. This reduces the coding skills needed by a Ul (user 

7 interface) designer. The Ul designer only needs to be concerned with the 

8 formatting and presentation of data, deciding what fonts, colors and graphics 

9 to use and the layout of the page, and not with writing code to retrieve data 
10 and initiate actions. 



SI 1 1 The flow chart of Figure 4 illustrates the processing steps, described 

hi 12 above, undertaken by the system when the request is submitted by a user. 

'b 13 When a user request is received 60, content engine 32 determines whether 

O 14 it is necessary to instantiate a new workflow 62. In an internet environment, 

O 15 a user request is correlated with a particular session. If an incoming request 

Q 

□ 16 is part of an active session which has a workflow already in progress, a new 

17 workflow is not required. If a new workflow module is required, content 

18 engine 32 determines an appropriate configuration, and initializes a new 

19 workflow module 66. Preferably, the workflow modules are established in an 

20 object oriented environment, and simply initializing a new instance of the 

21 appropriate workflow module is enough. Step 54 includes a determination of 

22 which workflow module is to be invoked from among those available, as well 



Declaration 
Attorney Docket No. 0544MH-40021 
Page 16 



1 as establishing parameters such as the expertise and the identify of the user 

2 which can affect which views are to be presented. Once the new workflow 

3 has been instantiated 66, the incoming request is passed to it 68. 

4 If the incoming request is made with respect to an existing workflow 

5 module, that module is restored 70 and the request is passed to it 68. 

6 Between calls to a process module, the state of the module is saved to a 

7 temporary memory, sometimes referred to as "persisting its state". Between 

8 requests, the process module is not doing anything. It is reactivated from 

9 temporary storage only when a request is received, and will be returned to 

1 0 an inactive state after operations on that request are complete. 

11 This restoration allows state information to be retained in what is 

12 essentially a stateless environment. By instigating a new workflow module 

1 3 for each session, all can operate independently and properly retain state. 

14 After the request is passed to the workflow module, various workflow 

15 operations are performed 72. These operations will be detailed further in 

16 connection with Figure 5. After the process module performs its workflow 

1 7 operation 72, a logical view to be presented to the user is returned 74. Along 

18 with the identification of the logical view is all data which is necessary to be 

19 returned to the user in response to the request just handled. This can be, for 

20 example, information such as confirmation of an order, pricing information 
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1 and delivery schedules, and similar information which is presented to the 

2 user in the format set forth in the appropriate view. 



00 



3 After the logical view to be presented is obtained, the process module 

4 workflow state is saved 76, to remain quiescent until a next request is 

5 received. The content engine then selects a physical view 78 which 

6 corresponds to the logical view received from the process module. The 

7 physical view is resolved to the channel adapter 80, and a formatted view 50 

8 is selected to be returned to the user 82. 

9 The flow chart of Figure 5 illustrates the steps taken within the 



Bi 10 workflow operations Block 72 of Figure 4. These steps are taken within the 



yi 1 1 workflow module itself. 

H 

^ 12 When a request is received 90, the process module determines 

a 

U 13 whether the request is valid 92. Validity of a request depends upon both the 

q 14 current state of the process module and the user entered values included in 

□ 

p 15 the request. If the request is not valid, an error is returned 94 to content 

16 engine 32. Error handling may be handled in several different ways, 

17 including selection of an appropriate logical error view by content engine 32. 

1 8 Returning an error 94 is similar to returning a logical view, wherein the view 

1 9 returned is an error page. 

20 If the incoming request is valid 92, the process module has several 

21 operations which it may undertake. The three steps shown in Figure 5, 
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1 retrieving data from the underlying business system 96, initiating 

2 transactions 98, and updating the underlying system 100, are typical actions 

3 undertaken by process modules. It may not be necessary to perform any or 

4 all of these steps in any particular state; the actual steps to be performed are 

5 application specific and determined by the current state of the process 

6 module and the user input. 

7 The processes performed are made with the underlying business 

8 system. For example, goods can be ordered, data bases updated, and data 

9 retrieved to be presented to the user. All of these steps which occur are 

10 transparent to the user, with only the end result being returned. After all 

11 application logic steps 96-100 are performed, the process module 

12 determines the next state into which it should change 102, and returns an 

13 identification of a logical view to the content engine 104. Along with an 

14 identification of this logical view is all information necessary to be placed into 

1 5 the view for presentation to the user. 

16 The above description has been with reference to content engine 32. 

17 The same process modules 40 used with content engine 32 can also be 

18 used with content engine 34 which delivers views into a different channel. 

19 The underlying process modules encapsulate the underlying business 

20 workflow, such as the process of taking and confirming an order. If that 

21 order is taken over a channel such as a telephone, limited to either voice 

22 recognition or entry of data using a telephone key pad, the presentations to 
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1 an end user are significantly different than the graphically oriented views 

2 presented to a user over an internet connection. However, the underlying 

3 information processed by the process modules 40 and the logical view 

4 returned by them, can be exactly the same. 

5 A different channel adapter 48 and different set of views 52 are 

6 provided for such different channels. This allows the same process 

7 modules, and in actuality nearly identical versions of the content engines, 32, 

8 34, to support widely different communication channels. By simply providing 

9 different interface views, which may be somewhat of a misnomer in the case 

10 of a telephone interface, the same underlying business processes can be 

1 1 used for widely different interface channels. 

12 The described system provides a number of advantages over prior art 

13 systems. The described modularity means that different implementers can 

14 be used for process modules and presentation views. Once a process 

15 module has been prepared for a particular application, it can be quickly and 

16 easily adapted to new communication channels which may come into 

1 7 existence or which are newly supported by the owner of the application. The 

18 implementers who write process modules need not be experts at techniques 

19 for presenting information to users, and user interface programmers need 

20 not be experts at performing the underlying business processes. This not 

21 only simplifies preparation of an application in the first place, but simplifies its 

22 maintenance by breaking problems into smaller, conceptually logical parts. 
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While the invention has been shown in only one of its forms, it is not 
thus limited but is susceptible to various changes and modifications without 
departing from the spirit thereof. 
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